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ABSTRACT 


The  goal  of  Project  SUE  at  the  University  of  Toronto  is  to  con¬ 
struct  a  reliable  and  understandable  operating  system  based  on  ideas 
drawn  from  other  systems  and  from  operating  systems  literature.  In 
this  paper,  we  present  a  discussion  of  some  of  the  choices  and 
decisions  that  have  been  encountered  during  the  design  of  the  SUE 
system.  Besides  selecting  an  overall  system  structure,  we  have  had 
to  develop  a  compatible  set  of  mechanisms  for  communication,  control, 
protection,  resource  allocation,  and  accounting.  We  have  attempted 
to  evaluate  the  practical  worth  of  some  conceptual  ideas,  to  test  in 
a  full-scale  system  some  ideas  proven  useful  in  small  systems,  and  to 
assess  the  mutual  compatibility  of  some  individually  useful  mechanisms. 
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INTRODUCTION 

"It  is  absurd  to  separate  the  study  of  designing  from  the  prac¬ 
tice  of  design."  (Christopher  Alexander) 

Project  SUE  at  the  University  of  Toronto  is  developing  an 

operating  system  for  the  IBM  System/360  family  of  computers.  We  are 

basing  our  work  as  much  as  possible  on  previous  research  in  operating 
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systems,  including  that  of  Dijkstra,  *  Lampson,  Brinch  Hansen,  and 
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the  MULT ICS  group.  *  *  Their  ideas  have  been  tested  in  actual 
systems,  but  separately,  and  on  uncommon  machines.  We  wish  to  combine 
their  ideas  and  the  ideas  of  others  in  a  system  for  a  widely  available 
machine . 

In  Project  SUE,  we  have  attempted  not  only  to  build  an  operating 
system,  but  also  to  learn  how  to  organize  a  large  software  project. 

To  this  end,  we  have  attempted  to  structure  and  document  the  project 
itself  as  well  as  the  system. 

We  have  set  high  standards  for  the  system.  We  want  it  to  be 

efficient.  We  want  it  to  be  extensible  in  the  sense  that  it  is 

possible  to  append  various  protected  subsystems  which  each  serve  a 

community  of  users.  Above  all,  we  want  the  system  to  be  reliable  and 

understandable.  We  make  no  attempt  to  compete  with  generality  of 

existing  operating  systems.  Rather,  we  are  creating  an  operating 

4 

system  nucleus  (in  the  sense  of  Brinch  Hansen  )  which  can  be  extended 
to  support  particular  applications.  The  system  nucleus  is  designed  to 
support  simultaneously,  for  example,  an  interactive  system  and  an 
independent  batch  monitor. 


. 
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This  paper  presents  our  objectives,  and  how  they  have 
influenced  our  selection  among  reasonable  alternatives  in  some 
design  decisions.  This  material  has  not  arisen  from  abstract  dis¬ 
cussions  of  the  theory  of  operating  systems.  It  comes  from  the 
specification,  detailed  design  and  partial  implementation  of  a 

g 

system.  A  description  of  the  system  design  is  available  elsewhere.  5 
Here,  we  will  only  discuss  some  aspects  of  the  design  process. 

SYSTEM  STRUCTURE 

The  concept  of  processes  lias  been  useful  in  understanding  and 
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designing  operating  systems.  ’  ’  ’  Each  process  proceeds  asynchro¬ 
nously  as  if  executing  on  its  own  (virtual)  machine,  except  when 
mechanisms  for  the  explicit  interaction  of  processes  are  invoked. 
These  interactions  may  depend  on  relationships  among  the  processes. 
For  example,  processes  may  be 

1)  regarded  as  equals, 

or  2)  related  in  a  tree-structured  hierarchy. 

The  latter  situation  arises  if  each  process  (after  the  first  one)  is 
created  by  another  process.  In  what  we  call  the  creation  tree,  a 
process  is  a  son  of  the  process  which  created  it,  and  the  father  of 
any  process  which  it  creates.  While  equality  among  processes  is  a 
simple  relationship,  the  weak  system  structure  it  imposes  makes  other 
goals  (understanding  the  system,  assuring  its  reliability,  and 
establishing  its  correctness)  difficult  to  attain.  A  hierarchy  among 
the  processes  specifies  a  logical  order  in  which  to  understand  them 
and  demonstrate  their  correctness. 


Digitized  by  the  Internet  Archive 
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The  virtual  machine  upon  which  a  process  executes  is  defined 
by  the  set  of  operations  supported  for  the  process  by  other  processes, 
lower  level  software,  and  hardware.  Each  process  should  be 
sufficiently  simple  that  its  correct  operation  can  be  demonstrated 
(on  the  assumption  that  its  virtual  machine  operates  correctly) .  If 
the  correct  operation  of  a  virtual  machine  does  not  depend  on  the 
correctness  of  any  process  using  it,  then  a  logical  order  for  under¬ 
standing  and  demonstrating  the  correctness  of  the  system  is  apparent. 

It  is  possible  to  distinguish  between  types  of  process 
hierarchies  in  which  virtual  machines  are 

1)  completely  ordered, 
and  2)  partially  ordered. 

In  the  former  case,  the  system  is  viewed  as  a  sequence  of  increasingly 

sophisticated  virtual  machines  ("onion-like  layers").  The  lowest  level 

virtual  machine  corresponds  to  the  hardware,  and  each  higher  level  is 

created  by  adding  a  layer  of  software  (possibly  composed  of  processes) 

to  the  previous  virtual  machine.  Dijkstra  has  described  the  T.H.E. 

2 

system  in  terms  of  six  levels  of  virtual  machines.  Every  process  in 
such  a  system  is  associated  with  the  level  of  virtual  machine  upon 
which  it  executes.  When  virtual  machines  are  completely  ordered,  any 
two  processes  are  related  in  one  of  two  ways;  either  they  have  the  same 
virtual  machine,  or  one  of  them  helps  provide  the  virtual  machine  used  by 

the  other.  A  more  general  process  hierarchy  results  when  virtual  machines 
are  only  partially  ordered.  Independent  processes  then  need  not  have 
the  same  virtual  machine. 
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The  SUE  system  structure  permits  hierarchies  of  the  latter 
type  although  several  onion-type  layers  are  distinguishable  and 
worthy  of  mention.  The  Kernel  is  a  layer  of  software  which  uses 
the  hardware  to  implement  processes  (their  creation,  destruction 
and  communication),  protection,  simple  management  of  memory  and 
channels,  and  timing  facilities.  The  innermost  group  of  processes 
uses  the  Kernel  to  create  the  Nucleus ,  a  more  sophisticated  virtual 
machine  which  provides  disk  files,  peripheral  input  and  output 
facilities,  and  mechanisms  for  measurement  and  accounting. 

The  virtual  machines  used  by  the  processes  which  form  the 

the  Nucleus  can  be  partially  ordered  with  respect  to  sophistication. 

It  is  possible  to  create  a  set  of  virtual  machines  which  are 
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facilities  which  will  not  be  used  by  the  corresponding  processes. 

This  corresponds  to  imposing  an  onion-type  hierarchy  on  the  processes 
in  the  Nucleus . 


There  are  many  ways  of  grouping  operating  system  activities  to 
form  processes.  At  one  extreme  each  conceptually  asynchronous  activit) 
might  be  carried  out  by  a  separate  process.  However,  asynchronism 
among  activities  does  not  necessarily  justify  the  existence  of  several 
processes  with  frequent  interactions  among  them.  For  example,  at  one 
time  we  planned  to  have  a  process  to  manage  each  disk  spindle  and 
each  disk  control  unit.  However,  each  disk  spindle  manager  would 
interact  with  a  control  unit  manager  so  frequently  that  little 
asynchronous  activity  would  occur.  We  have  concluded  that  the  extra 
processes  are  not  justified  and  that  all  disk  spindles  and  all  disk 
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control  units  should  be  managed  by  a  single  process.  Other  aggrega¬ 
tions  of  activities  have  been  adopted,  and  the  SUE  Nucleus  now 
consists  of  only  seven  processes. 

COMMUNICATION  AND  COOPERATION  AMONG  PROCESSES 

Because  our  operating  system  is  based  on  the  cooperation  of 

processes,  the  communication  mechanisms  must  be  efficient,  easy  to 

understand,  and  easy  to  use,  but  secure  from  unauthorized  use  and 
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the  danger  of  deadlock.  ’  *  Many  schemes  for  process  interaction 
have  been  developed.  Each  is  based  on  either 

1)  shared  data 
or  2)  message  passing. 

Process  interactions  in  Dijkstra's  T.H.E.  system  use  shared  data  called 
semaphores  and  special  indivisible  operations  for  manipulating  them.'*' 

In  a  message  passing  scheme  suggested  by  IVulf,  each  process  possesses 
a  number  of  ports ,  and  each  port  is  the  interface  to  a  communication 
link  with  another  process.^  Establishing  the  communication  link  may 
be  an  expensive  operation,  but,  with  the  link  established,  less  check¬ 
ing  is  necessary  as  each  message  is  passed.  A  mailbox  with  several 
message  slots  may  be  inserted  in  a  communication  link  to  provide 
automatic  buffering  of  messages.^  Because  we  desire  autonomy  among 
processes  in  Project  SUE,  a  message  passing  form  of  communication  is 
more  appropriate  than  a  scheme  based  on  shared  data. 

Message  passing  through  ports  and  mailboxes  was  initially  accepted 
as  the  mechanism  for  interprocess  communication  in  Project  SUE.  Much 
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work  was  done  examining  protocols  for  establishing  and  using 
communication  links,  and  making  sure  that  deadlock  would  not  occur. ^ 
The  scheme  seemed  to  be  compatible  with  our  goals  of  making  the 
system  efficient  and  understandable. 

Only  after  much  more  time  and  thought  did  we  identify  some  prob¬ 
lems  with  communication  through  ports  and  mailboxes  alone.  One 
problem  was  establishing  the  communication  links.  A  process  must 
name  the  process,  or  class  of  processes,  with  which  it  wishes  to 
communicate.  Unless  system-wide  standard  names  are  established, 
another  significant  communication  mechanism  is  required  to  coordinate 
the  naming  of  processes. 

Processes  which  provide  a  service,  such  as  device  allocation  or 
file  system  management  have  special  communication  requirements.  A 
large  number  of  processes  wish  to  use  each  such  service.  With 
extensibility  as  a  design  goal,  the  number  of  processes  that  can 
simulteneous ly  have  a  communication  link  to  a  particular  service 
process  should  not  be  limited  (although  such  limits  exist  in  many 
systems) .  Providing  each  service  process  with  enough  ports  to 
guarantee  that  competition  could  not  lead  to  deadlock  would  require 
the  commitment  of  an  excessive  amount  of  memory.  We  considered 
adding  a  second  form  of  mailbox  which  could  attach  a  single  port  of 
a  service  process  to  an  unbounded  number  of  other  ports.  However, 
the  complexity  of  such  objects  and  new  problems  in  their  design 
compelled  us  to  seek  a  better  solution. 
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Mailboxes  are  not  appropriate  for  passing  large  messages  (such 
as  block  transfers  on  input  and  output).  Not  only  is  memory  space 
committed  unnecessarily  to  mailbox  buffers,  but  each  message  must 
be  moved  twice  (source  to  mailbox  buffer,  then  mailbox  buffer  to 
destination)  when  one  move  could  suffice.  Finally,  more  careful 
analysis  indicated  that  passing  even  small  messages  through  mailboxes 
would  not  be  as  efficient  as  we  had  hoped. 

Another  mechanism  was  suggested  to  supplement  communication 

through  mailboxes.  We  call  service  processes  faci lities  and  they  are 

17 

used  as  are  the  monitors  described  by  Hoare.  A  requesting  process 
contacts  a  facility  directly  by  issuing  a  facility  call .  The  call  is 
unbuffered,  and  the  requesting  process  cannot  proceed  until  the 
facility  completes  the  requested  service. 

For  the  sake  of  system  structure,  we  restrict  which  processes 
are  allowed  to  call  on  any  particular  facility.  A  straight-forward 
mechanism  for  representing  this  information  is  an  access  matrix,  whose 
(ijj)^1  element  indicates  whether  process  i  may  call  upon  facility  j. 
However,  such  a  matrix  is  not  easily  kept  current  in  an  environment 
where  processes  are  dynamically  created  and  destroyed.  Also  the 
access  matrix  does  not  contribute  to  system  structure. 

By  relating  permissibility  of  facility  calls  to  the  creation  tree, 

* 

a  hierarchical  system  structure  may  be  enforced  implicitly.  Three 
alternatives  we  considered  are  that  a  facility  may  be  called  upon 

1)  only  by  its  descendants, 

2)  only  by  its  descendants,  and  by  its  younger 
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brothers  and  their  descendants, 
or  3)  only  by  processes  farther  from  the  root  of  the 
creation  tree. 

The  second  of  these  represents  a  compromise  between  the  other  two. 
The  first  is  the  simplest  and  most  understandable.  The  advantage 
of  the  second  alternative  over  the  first  is  that  processes  which 
provide  a  facility  are  not  compelled  to  also  create  and  monitor 
sons.  The  third  alternative  was  rejected  because  the  second  repre¬ 
sents  a  more  structured  solution  which  does  not  greatly  impair 
flexibility.  Choosing  between  the  first  and  second  alternatives 
was  difficult.  After  several  weeks  of  debate,  expediency  of 
implementation  caused  us  to  permit  facilities  to  be  called  upon 
only  by  their  descendants  (first  alternat-ive) . 


The  facility  call  mechanism  solves  the  problems  of  naming  the 
process  to  be  contacted  and  of  allowing  service  processes  to  respond 
to  arbitrarily  many  customers.  We  soon  realized  that  facility  calls 
were  also  sufficient  for  all  other  communication  needs  in  the  SUE 
system.  Conversations  between  any  two  processes  are  accomplished  by 
facility  calls  from  each  to  one  of  their  common  ancestors.  Service 
requests  can  be  buffered  by  creating  a  son  to  provide  the  buffering. 
Thus,  in  order  to  reduce  the  number  of  different  system  objects  and 
mechanisms,  mailboxes  and  ports  have  been  eliminated  from  the  SUE 
System.  All  interprocess  communi cation  is  done  with  the  facility  call 


mechanism. 
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Because  all  facility  calls  are  directed  toward  the  root  of  the 
creation  tree,  deadlock  can  be  prevented  by  assuring  that  each 
facility  completes  each  user  request  within  finite  time.  Certain 
situations  require  that  facility  calls  be  used  in  an  unusual  manner. 
The  innermost  Nucleus  processes  are  situated  in  the  system  structure 
where  disk  files  and  typewriter  communication  are  not  available. 

Yet  they  need  to  report  error  conditions  to  the  operator,  and  record 
accounting  and  measurement  information  in  disk  files.  Thus  the 
innermost  Nucleus  processes  occasionally  require  the  assistance  of 
a  descendant  which  is  at  a  level  of  the  process  hierarchy  where  disk 
files  and  operator  communication  are  available.  This  descendant, 
known  as  the  Special  Condition  Manager,  effectively  provides  service 
to  its  ancestors  in  the  creation  tree.  So  that  no  process  waits  for 
a  descendant,  the  facility  call  mechanism  is  employed  as  follows: 

The  Special  Condition  Manager  creates  a  son  for  each  ancestor  which 
may  require  its  services.  Each  son  issues  a  facility  call  on  the 
corresponding  ancestor,  requesting  the  next  "special  condition." 

When  a  process  wishes  service  from  the  Special  Condition  Manager,  it 
simply  completes  the  service  call  (which  should  be  outstanding) 
indicating  what  "special  condition"  exists.  If  the  son  of  the  Special 
Condition  Manager  has  not  issued  the  facility  call,  the  process  must 
not  wait  for  the  call  to  occur,  but  must  take  some  alternative  action. 
Thus,  information  may  be  lost  if  the  Special  Condition  Manager  does 
not  react  with  sufficient  speed,  but  special  conditions  cannot  dead¬ 
lock  the  system. 
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AUTHORI ZATI ON ,  ACCOUNTING  AND  MEASUREMENT 

An  operating  system  should  provide  mechanisms  to  prevent 
unauthorized  and  excessive  use  of  system  resources.  It  should  also 
be  able  to  measure  resource  usage  and  attribute  it  to  processes  or 
groups  of  related  processes. 

The  central  mechanism  in  the  authorization  and  accounting 
functions  of  the  SUE  system  is  the  concept  of  capabi  lities  .  ^ 

A  capability  is  a  control  block  associated  with  a  process  which 
indicates  that  the  process  is  authorized  to  use  a  particular  resource 
in  a  particular  manner.  Processes  are  not  allowed  to  tamper  with  the 
information  held  in  capabilities  (especially  their  own!).  The  ability 
to  create  and  modify  capabilities  is  restricted  to  a  carefully  pro¬ 
tected  routine  deep  in  the  Kernel. 

Capabilities  are  but  one  possible  way  of  representing  protection 

information.  Lampson  has  described  a  theory  of  protection  based  on 

3 

objects  (resources  and  processes)  and  domains .  A  process  executes 
in  a  particular  domain.  A  domain  is  defined  by  the  manner  in  which 
processes  executing  in  that  domain  are  authorized  to  use  the  objects 
of  the  system.  When  processes  are  units  of  protection  as  well  as 
units  of  asynchronous  activity,  the  domain  of  a  process  may  be  repre¬ 
sented  as  a  list  of  capabilities,  one  for  each  resource  accessible  by 
the  process . 

An  alternative  manner  of  representing  protection  information  is 
to  associate  with  each  resource  a  list  of  processes  authorized  to  use 
it.  This  method  is  less  desirable  in  the  SUE  system  because  facilities 
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do  not  discriminate  among  processes  in  providing  service.  Using 
the  capability  representation  allows  each  process  to  allocate  the 
right  to  use  a  facility  among  itself  and  its  sons. 

In  the  SUE  system,  we  distinguish  three  varieties  of  capabilities. 
One  governs  resource  usage  qualitatively  (permission  to  use  a  disk 
drive  or  to  access  a  particular  file),  while  another  governs  quanti¬ 
tatively  (the  number  of  files  which  may  be  created  or  the  number  of 
file  read  operations  which  may  be  done).  A  qualitative  capability 
is  known  by  the  Kernel  to  contain  a  word  of  Boolean  information 
representing  access  rights,  while  a  quantitative  capability  is  known 
to  contain  a  number.  The  number  may  be  decremented  by  the  facility 
whenever  the  capability  is  used  to  request  use  of  resource.  This 
is  similar  to  punching  a  "meal  ticket"  each  time  a  meal  is  consumed. 

When  the  count  reaches  zero,  the  capability  no  longer  has  value. 

The  third  variety  of  capability  contains  information  which  is  inter¬ 
preted  not  by  the  Kernel,  but  only  by  the  process  which  created  the 
capability. 

We  have  chosen  not  to  use  two  features  of  general  capability 
schemes.  First,  we  do  not  allow  rights  to  a  resource  to  be  passed 
between  arbitrary  processes  by  transferring  a  capability.  In  order 
to  maintain  system  structure  and  to  avoid  difficult  questions  about 
how  to  dispose  of  leftover  capabilities  when  a  process  is  destroyed, 
we  have  restricted  all  capability  transactions  to  occur  between 
either  father  and  son  or  facility  and  user.  Second,  we  do  not  use 
capabilities  to  repi'esent  authorization  information  about  some  resources 


■  ' 
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necded  by  every  process  (such  as  processor  time,  and  memory  space). 

For  resources  common  to  all  processes,  we  use  an  efficient  encoding 
of  authorization  information.  The  routines  for  manipulating  capabilities 
would  be  made  too  complex  if  they  had  to  deal  with  each  special 
encoding,  so  the  capability  concept  is  not  used  for  these  resources. 

During  much  of  the  design  of  the  SUE  system,  we  believed  that 
capabilities  would  have  to  be  associated  with  longer- lived  entities 
than  processes.  Consider  a  permanent  disk  file  which  is  created  by 
one  process,  then  used  from  time  to  time  by  other  processes.  The 
succession  of  processes  each  must  have  a  capability  for  accessing 
the  disk  file,  yet  their  life  spans  need  not  overlap.  We  faced  the 
problems  of  how  to  keep  the  capabilities  in  the  system  and  recognize 
which  capabilities  should  be  given  to  a  particular  new  process.  We 
planned  to  have  permanent  entities,  called  sponsors ,  whose  capabilities 
would  be  kept  in  disk  files.  Sponsors  correspond  more  or  less  to 
people  who  pay  for  use  of  the  computer  system.  Each  process  which 
deals  with  a  permanent  file  will  have  been  initiated  on  behalf  of 
some  person  (sponsor).  Thus,  each  disk  file  capability  could  be 
associated  with  a  sponsor,  and  transferred,  upon  request,  to  processes 
created  later  on  behalf  of  that  sponsor. 

Further  investigation  revealed  difficulties  with  implementing 
sponsors  within  the  Nucleus.  First,  it  seemed  necessary  to  give  the 
power  of  transforming  data  into  capabilities  to  a  process  whose  virtual 
machine  provided  disk  files,  yet  we  wished  to  use  capabilities  to  pro¬ 
tect  disk  files.  Second,  the  scheme  would  increase  the  complexity  of 
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the  flow  of  capabilities  in  the  system.  At  process  creation, 
capabilities  would  come  not  only  from  the  father,  but  also  from  the 
sponsor.  Worse  yet,  at  process  destruction,  a  decision  mechanism 
would  be  needed  to  determine  which  of  the  remaining  capabilities 
were  to  be  returned  to  the  sponsor  and  which  to  the  father. 

We  have  since  found  an  alternative  solution  to  the  problem  of 
capabilities  for  permanent  disk  files.  Since  disk  space  is  to  be 
allocated  among  the  independent  sub-systems  being  supported  by  the 
Nucleus,  and  then  subdivided  by  each  among  its  sons,  the  responsibility 
for  associating  subdivisions  of  file  space  with  people  (or  sponsors) 
can  be  left  to  each  process  which  divides  its  space  among  its  sons. 
Further,  by  requiring  that  each  suballocation  consist  of  a  subset  of 
the  father's  file  space,  the  father  is  able  to  retain,  in  a  single 
capability,  the  authorization  to  the  entire  file  space  which  it  con¬ 
trols.  Only  when  a  subsystem  process  is  destroyed  is  there  still  a 
problem  of  where  to  keep  the  file  capability.  By  requiring  the  number 
of  independent  sub-systems  to  be  bounded  and  small,  we  can  store  the 
file  space  capability  for  each  sub-system  within  the  Nucleus.  This 
approach  eliminates  the  problem  of  transferring  capabilities  to  and 
from  peripheral  storage  and  moves  the  sponsor  structure  completely 
outside  the  Nucleus.  The  complexity  of  a  disk  resident  sponsor  struc¬ 
ture  makes  such  a  move  desirable. 

Mechanisms  for  accounting  and  measurement  of  resource  usage  are 
implemented  using  capabilities.  Essentially,  every  process  is  held 
accountable  for  the  resource  usage  represented  by  any  capability  it. 
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receives  from  its  father  or  a  facility.  If  it  does  not  wish  to  be 
financially  responsible  for  the  resource  usage  of  its  sons,  it  must 
record  the  value  of  the  capabilities  passed  to  each  son  and  the 
value  of  the  capabilities  returned  when  the  son  is  destroyed.  In 
this  manner,  resource  usage  can  be  attributed  to  individual  pro¬ 
cesses  at  as  many  levels  of  the  system  as  is  desired. 

Perhaps  the  strongest  motivation  for  using  capabilities  as  the 
mechanism  for  authorization  and  resource  allocation  is  that  we  wish 
the  system  to  be  conveniently  extensible.  Since  we  cannot  define 
the  universal  resource  set,  we  have  provided  mechanisms  so  that 
processes  can  define  arbitrary  resources  and  can  authorize  and  account 
for  their  usage. 

RELIABILITY  AND  EXTENSIBILITY 

Our  original  proposal  contains  the  sentence,  "A  design  criterion 
is  that  neither  the  erroneous  nor  the  malicious  program  shall  be  able 
to  'crash'  any  other  user,  or  the  system,  under  any  combination  of 
circumstances."  We  initially  interpreted  this  as,  "No  process  should 
ever  have  to  put  itself  at  the  mercy  of  another  process."  By  our 
selection  of  system  structure  and  mechanisms  for  resource  allocation 
and  authorization,  we  have  designed  a  system  in  which  no  process  can 
cause  incorrect  operation  of  any  process  which  contributes  to  the 
support  of  its  virtual  machine  (that  is,  any  process  closer  to  the 
Kernel  in  the  creation  tree) .  Further,  two  processes  on  different 
branches  of  the  creation  tree  cannot  interfere  with  each  other.  Thus 
protection  in  the  SUE  system  provides  two-way  insulation  ("firewalls") 
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between  independent,  non-interacting  processes,  and  one-way  insula¬ 
tion  of  processes  from  their  descendants  in  the  creation  tree. 

Every  process  can  be  mistreated  by  any  facility  from  which  it 
requests  service,  and  it  lias  no  protection  against  the  whims  of  its 
father.  However,  we  do  not  feel  that  it  is  a  compromise  to  our 
original  goal  to  require  a  process  to  trust  the  virtual  machine  upon 
which  it  runs.  Rather,  we  have  learned  more  precisely  what  our 
original  goal  was  and  how  inadequately  defined  the  terms  "user"  and 
"system"  are. 

Because  extensibility  is  among  our  goals,  we  are  unwilling  to 
establish  a  clear  distinction  between  "system"  processes  and  "user" 
processes.  Definition  of  "user"  is  always  relative  to  a  particular 
process.  The  descendants  of  any  process  form  the  set  of  potential 
users  of  that  process.  All  mechanisms  within  the  Nucleus  are 
intended  to  be  understandable  and  flexible.  They  may  be  helpful  to 
subsystems  which  are  appended  to  the  Nucleus.  We  hope  subsystems 
will  exploit  the  mechanisms  provided  within  the  Nucleus.  However, 
subsystems  may  choose  to  conceal  the  Nucleus  mechanisms  from  their 
descendants.  For  example,  the  distinction  among  the  varieties  of 
capabilities,  or,  in  fact,  even  the  existence  of  capabilities  could 
be  concealed  by  a  subsystem  from  its  users.  Similarly,  the  communi¬ 
cation  mechanism  used  within  the  Nucleus  can  be  replaced.  A  sub¬ 
system  might,  for  example,  choose  to  implement  mailboxes  as  the 
mechanism  for  communication  among  its  users. 
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IMPLEMENTATION  LANGUAGE  AND  PROGRAMMING 


Our  desire  to  make  the  SUE  system  understandable,  modifiable, 

and  extensible  along  with  our  desires  to  facilitate  coding  and 

demonstrate  correctness  made  the  use  of  assembly  language  for 

implementation  unacceptable.  Although  several  systems  programming 

20  21  22  23 

languages  have  been  developed,  ’  5  ’  '  we  chose  to  use  an  available 

24 

compiler  generator  to  design  and  implement  a  system  language 

8  9  25  26 

specifically  for  SUE.  This  language  is  documented  elsewhere.  5  ’  * 

It  features  convenient  definition  of  new  data  types  and  control 
structures  which  facilitate  writing  understandable  programs. 


Hoare's  first  thesis  on  the  use  of  high  level  languages  in 

27 

constructing  large  programs  states: 

"Programming  languages  are  little  help  in  the  construction  of 
large  programs. 

1.  To  design  a  'language'  as  part  of  design  and  implementation 
of  a  big  system  is  essential. 

2.  To  'implement'  this  language  is  disastrous. 

3.  To  use  a  language  designed  and  implemented  for  any  other 
special  purpose  is  of  doubtful  benefit." 

Hoare's  thesis  is  a  valuable  warning  of  potential  danger,  but  our' 
experience  indicates  that  disaster  is  not  inevitable.  Language  design 
and  implementation  indeed  absorbed  more  project  resources  than  was 
anticipated.  However,  the  benefits  of  a  well-designed,  high-level 
language  are  being  felt  in  both  coding  and  validation. 
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The  technique  of  structured  programming  has  been  used 

2  2  8  29 

successfully  in  the  implementation  of  several  systems.  *  ’  We 
have  found  that  the  use  of  structured  programming  eases  the  transi¬ 
tion  from  design  to  coding,  and  facilitates,  attempts  to  demonstrate 
the  correctness  of  the  system. 

PROJECT  MANAGEMENT 

Our  goal  in  Project  SUE  has  been  not  only  to  build  an  operating 
system,  but  also  to  learn  about  the  process  of  building  operating 
systems.  For  this  reason,  we  have  generated  extensive  documentation 
of  what  the  system  design  is  and  how  it  came  to  be  that  way.  A  large 
(and  growing)  workbook  incorporates  project  history,  project  status, 
problems  as  they  are  discovered,  solutions  as  they  are  proposed,  and 
decisions  as  they  are  made.  Hie  development  of  this  paper  has  been 
based  on  material  contained  in  the  project  workbook. 

At  intervals  of  about  four  months,  we  have  written  project 
evaluation  reports  (Checkpoint  Reports).  At  each  checkpoint,  we  have 
thought  about  how  well  we  are  progressing,  how  well  we  are  fulfilling 
our  goals,  and  whether  some  redirection  of  the  project  is  needed.  In 
the  narrow  view,  Checkpoint  Reports  interrupt  our  technical  progress 
for  periods  from  three  days  to  three  weeks.  In  broader  perspective, 
Checkpoint  Reports  have  forced  us  to  periodically  reevaluate  our  goals 
and  priorities.  Without  scheduled  Checkpoints,  it  is  unlikely  that  we 
would  devote  enough  attention  to  these  topics. 

Technical  decisions  have  been  made  in  a  democratic  way  among  as 
many  as  six  people.  Democracies  tend  to  progress  slowly,  but  once  all 
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parties  are  convinced  of  a  decision,  confidence  in  the  decision  is 
often  greater  than  if  the  decision  had  been  made  by  an  individual. 

Some  particularly  difficult  decisions  have  been  resolved  by 
selecting  a  reversible  decision.  The  questions  could  not  be 
completely  investigated  in  the  time  we  were  willing  to  keep  a 
decision  pending,  so  we  assured  ourselves  that  the  decision  taken 
would  not  have  such  broad  impact  that  the  decision  could  not  be 
reversed  with  reasonable  effort. 

Although  we  intended  to  use  "existing  technologies",  design 
time,  not  programming  time,  has  been  our  scarce  resource.  Two 
reasons  for  this  have  been  that  most  of  the  designers  could  not 
devote  full  time  to  the  project,  and  that  the  system  language 
speeds  programming. 

CURRENT  STATUS 

This  paper  is  based  on  our  experience  during  the  first  fifteen 
months  of  Project  SUE.  As  of  July,  1972,  we  have  designed  a  systems 
implementation  language  and  implemented  a  subset  sufficient  for 
developing  the  SUE  Kernel  and  Nucleus.  The  system  structure  and  all 
mechanisms  for  process  interaction  have  been  designed  and  their 
manner  of  use  documented.  The  primitive  operations  provided  by  the 
Kernel  are  designed  and  are  being  implemented.  Some  Kernel  modules 
have  been  demonstrated  correct.  Most  Nucleus  processes  are  designed 
and  are  being  implemented.  We  are  encouraging  students  to  create 
diverse  subsystems  to  be  run  under  the  SUE  Nucleus. 
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CONCLUSION 

We  started  Project  SUE  with  the  intention  of  building  a  reliable, 
hierarchical,  extensible  system  in  which  no  distinction  is  made 
between  "user"  process  and  "system"  processes.  We  needed  a  compati¬ 
ble  set  of  convenient,  structured  mechanisms  for  control,  communica¬ 
tion,  authorization,  and  accounting.  We  knew  of  "existing  technologies" 
for  handling  each  of  these  problems  individually,  but  not  of  a  unified 
set  of  mechanisms  which  treated  all  the  problems.  We  underestimated 
the  conceptual  design  effort  involved  in  modifying  the  existing 
technologies  to  make  them  mutually  compatible  and  appropriate  for  an 
extensible  system.  Most  of  the  systems  from  which  we  have  drawn 
ideas  were  successful  at  least  in  part  due  to  their  limited  goals. 

We  have  slowly  become  aware  that  our  original  goals  were  very 
ambitious . 

A  notable  change-  in  our  approach  has  occurred  since  the  start  of 
the  project.  Initially,  we  designed  the  most  general  mechanisms  which 
were  implementable . Recently,  we  have  designed  the  most  restricted 
mechanisms  which  would  satisfy  our  needs.  Partly  this  is  because  we 
now  have  a  much  sharper  picture  of  what  our  needs  are.  But,  also,  it 
reflects  a  trend  toward  practicality. 

The  change  in  approach  can  be  observed  in  several  areas.  The 
System  Language  was  fully  designed  early  in  the  project.  It  has 
become  apparent  that  much  of  the  generality  of  the  language  wa s 
costly  to  implement  without  contributing  greatly  to  the  goals  of  the 
project.  Early  in  the  project,  mailboxes  and  capabilities  in  their 
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general  sense  appealed  to  us.  Both  are  flexible,  powerful,  and 
expensive  mechanisms.  Recently,  we  have  realized  that  we  can  make 
the  system  structured  and  understandable,  by  using  capabilities  in 
a  more  constrained  manner,  and  using  a  more  restrictive  communication 
mechanism. 

It  is  important  to  the  future  of  the  "Theory  of  Operating 
Systems"  that  new  work  make  use  of  the  knowledge  of  previous 
successes  and  failures  in  the  area.  It  is  also  important  to  test 
in  full-scale  systems  the  adequacy  of  ideas  presented  initially  at 
conceptual  or  philosophical  levels.  Project  SUE  has  attempted  to 
do  both.  Frequent  introspection  has  also  allowed  us  to  extract  some 
knowledge  of  designing  from  our  process  of  design. 
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